Modern information technology provides a vast array of software to meet many different needs. However, after a need is identified, the shear volume of available technology and the lack of common architectures make generation and management of custom solutions difficult and expensive. Component software encourages encapsulation and reuse of software routines for decreasing program development and maintenance time. Distributed software systems allow software services, components, and objects to work together over network infrastructures such as Local Area Networks (LAN), Wide Area Networks (WAN), and the Internet. The current software world is littered with existing software systems, heterogeneous hardware platforms and heterogeneous software object models which all contribute to the complexity of distributed software systems.
Software systems which utilize distributed components first require a method to locate services or components on the network. Hardcoding addresses, configuration files, command line parameters, service broadcasting, naming systems, local or distributed repositories are all known methods that are used to locate services and components on the network. A summary of the more common of these conventional locating methods follows.
The Component Object Model (COM) method for locating components utilizes a registry file with a specific format. Non-COM software components cannot be stored in the COM registry. Object Linking and Embedding (OLE)/COM /ActiveX software components are accessible on a given computer only if they are registered in a local registry file. The COM registry file maps software component identifiers known as class identifiers (CLSIDs) to the file system location of a binary object and to type library information about the interface(s) of the server component. This provides a framework to make individual pieces of software available, but it is limited to COM objects and to the software that can access the local registry file.
This reliance on the local registry file unduly limits component availability and creates scaling problems if many computers need access to the registration information. While COM components may be stored on computers that are connected to a LAN and clients of these components may also reside on the LAN, COM does not take full advantage of the capabilities of LAN administration tools. Most often COM assumes its environment will be a single isolated computer. The COM object model enables COM components to interact, but does very little to enable component distribution.
Distributed COM (DCOM) adds remote execution and distributed naming to COM. DCOM locates components using the same mechanisms defined in COM (the location can be supplied by the client in a local Windows registry). In addition DCOM plans to use the NT 5.0 active directory where references to objects are distributed with the naming system. Once DCOM has located a component on the network it issues a remote procedure call to the destination system to access remote objects. DCOM improves upon COM, but DCOM still has limitations in the area of interoperation with heterogeneous object models, and in the use of common LAN administration tools.
Java applets and programs provide another architecture for locating distributed software components. Java applets are miniature programs that are executed while users view Internet information, such as World-Wide-Web pages. Java applets are linked or included in World-Wide-Web pages in a similar manner as images or other data with hard-coded references to an Internet HTTP address. When a user selects a highlighted or underlined portion of a web page that was linked to the Java applet, the Java applet is transferred across the Internet to the user's Web browser where the Java applet is executed. If the browser contains a Java interpreter, the Java applet (comprising Java byte codes) is loaded and executed by a Java Virtual Machine (JVM) embedded within the web browser.
The Java architecture is an improvement over the architecture for the COM model because in addition to the reference and interfaces, the software is also distributed dynamically. Components are hardware independent. However, the link or reference to a Java applet (class) across the Internet is a static physical reference at one moment in time. If the Java applet is moved, the web page cannot find it. In addition, Java applets and COM objects do not work together without custom written browsers and static object wrappers which perform the necessary interface transformations or adaptations.
Also, a Remote Method Invocation (RMI) architecture is included in the Java architecture which allows remoting between Java objects and remote execution of applets, thus creating a distributed object system. The RMI architecture includes a bootstrap registry which is used to locate distributed Java components. Although similar in concept to the local COM registry, the RMI bootstrap registry does not interoperate with objects other than Java objects and cannot store information about components for different object models as was the case for the local COM registry. Neither registry is fully scaleable or distributed across the network, and therefore objects cannot be managed as part of the object distribution system.
Another method for component discovery periodically broadcasts or advertises services across the network. One implementation of this is User Datagram Protocol (UDP) broadcasts in the TCP/IP protocol, while another implementation of this method is Novell's Service Advertisement Protocol (SAP). SAP provides a means for independently locating components (i.e., hard-coding of service location is no longer needed). However, this method consumes a significant amount of network bandwidth and is therefore an undesirable solution to locate components in a global network.
The Common Object Request Broker Architecture (CORBA) defines additional ways to locate components. At its most basic level, CORBA provides an implementation repository (similar to the RMI bootstrap registry or the COM local Windows registry); in addition, CORBA defines a binding service, an interface repository and optional naming and trading services. The trading service maintains a repository of object types and offers. The interface repository for CORBA is a runtime database containing interface definition language (IDL)-defined interfaces, where IDL is the standard language used in CORBA for specifying the interfaces of CORBA objects. Operationally, a provider of a new service on the network registers information about the new service with the implementation repository either directly or indirectly via a naming service or Trader service. Thereafter, a client on the network accesses the implementation repository either directly (static reference to known physical objects), or via naming or trading services which contain a logical representation of the CORBA objects that are available on the network at any point in time. The naming and trading services cross the boundary from physical object references to logical object references. This is an improvement over the COM and Java models for object location.
Specifically, the Trader service assures that the types and interfaces of the provided service matches the service requested by accessing the Trader type repository. The Trader obtains an object reference to the service offer from the trader offer repository which indexes the CORBA implementation repository. The object reference to the service offer is then passed back to the client so that the software objects can bind via the CORBA binding service.
The CORBA object model requires that CORBA be the design center for distributed systems and that all other object models must bridge to it. The CORBA object model addresses the need for interoperation between object models by requiring all non-CORBA objects to wear CORBA wrappers, or "jackets". To a CORBA system, all objects may interoperate as long as they "look" like CORBA objects. Accordingly, CORBA addresses problems associated with scaleability, location independence, and interoperability, by providing implementation repositories, interface repositories, and naming/trader services. However, in CORBA all objects must bridge to CORBA, and CORBA does not take full advantage of the abilities of LAN administration tools.
These conventional methods generally use different standards to create a single software component model and architecture (both hardware and software) known to work together. Yet, these standards do not allow management and integration of heterogeneous components. While integration among and changes to existing systems require significant re-engineering, the flexibility to adopt new technologies wanes as these systems become more complex. This results in conventional systems being "locked into" hardware, programming languages, software object models and distribution frameworks for well-known components and systems having controlled interactions. Within each system, object distribution, discovery, binding and management follow models that are tightly-coupled with a defined object model. Heterogeneity among such different known systems thus requires bridges and custom interfaces.
In summary, conventional component object models define their own independent object-model centric registries and repositories for locating distributed software objects. These registries are not integrated within object models, and they are limited to software objects. Currently, there is no object neutral global component registry with security access control. Also there is no component services registry having a common point of management for distributed components that enable interoperability among these independent registries. Moreover, management of components in a network is problematic because there is no single point of control. This problem becomes even more significant as the network grows in size.
For example, system administrators require the ability to control naming of components so that they can be efficiently located and accessed anywhere on a global network. It is undesirable for administrators and en-dusers to physically install and manage components at every node on the network. Also, component programmers are reluctant to provide access to software components without adequate safeguards that protect unauthorized use of their software. These issues have contributed to the delay in full acceptance of distributed component software.
The present invention addresses these issues and, in particular, is directed to a component server architecture that provides an infrastructure for administering, integrating, exposing and managing distributed heterogeneous components and services. More specifically, the present invention is directed to an architecture that facilitates discovery of, access to and interoperation among various components and software in a distributed system.
Therefore, it is an object of the present invention to provide a system for managing the location, distribution and access of various software, hardware, and data components and component object models distributed in a computer network.
Another object of the invention is to provide a component management system which internally supports various object modeling systems for integration within a directory services provider.
It is yet another object of the present invention to provide such a system which takes advantage of the capabilities of Internet servers.